-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
accept text/plain type by default for prometheus client scraping #24622
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
Pinging @elastic/integrations (Team:Integrations) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for reporting this!
they are not supported by current metrics parser
Does it produce failures in Metricbeat?
const ( | ||
promTextHeader = `text/plain;version=0.0.4;q=0.5,*/*;q=0.1` | ||
openmetricsHeader = `application/openmetrics-text; version=0.0.1,text/plain;version=0.0.4;q=0.5,*/*;q=0.1` | ||
acceptHeader = promTextHeader |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Metricbeat has two collectors, one for prometheus, and another one for openmetrics, they are mostly the same so far, but I think it would make sense if each collector configured the default headers of their choice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the comments. yeah but I think for application/openmetrics-text
the parser would only work for 'previous' openmetrics format, not the new one, so sending Accept: application/openmetrics-text
could give target endpoints the chance to respond with new format, while at this moment, text/plain
prometheus format should still be compatible from their perspective.
This PR is more like a workaround as being mentioned in the issue, the solution would still be updating the parser as suggested by @exekias .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder why application/openmetrics-text; version=0.0.1
includes the new openmetrics types 🤔 . Shouldn't that change be applied with a new version so as to be backwards compatible?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point. I think somehow that is not happening and hence breaking things.
16f1523
to
3512e9d
Compare
/test |
Looking at #17291 this header was added by Blake to work in general for all cases since these are the headers used by prometheus upstream too. In the issue that Blake tried to fix (#16870) I found a config that helps the user and might be helpful in this case too: #16870 (comment). @newly12 do you think sth like the following could work in your case?
|
thanks @ChrsMark , it should work by setting overridden header in config. concern is that this needs to be removed after the long term fix done in metricbeat and before prom text compatible removed(if they will) in various sdk. I would assume long term fix requires parser update(i.e. move to textparse?) and maybe effort for new types mapping, which sounds like may not happen in a short period of time.. |
@newly12 I will create a separate issue to track the investigation of the updates that are required (I will check |
@ChrsMark this is an issue everytime someone tries to report a metric of type info. especially when we use hints based autodiscover we cant keep setting headers for each use case. given that we dont natively support open metrics scraping at this time, how can we set that as the default header? we should not use it, unless we move to textparse which is the only native openmetrics parser at the moment. expfmt is more or less deprecated. |
Makes sense @vjsamuel , thanks for reporting this. I think we can proceed with this PR and merge it since as described at #24707 (comment) adding @jsoriano @exekias what do you think about merging this one? |
Sounds good to me. |
I'm ok with patching this way for now. One question on my end, where is |
Nowhere, we can remove it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's proceed with merging this one after we cleanup the unwanted headers.
b507e28
to
307060b
Compare
Thanks all! I've removed unnecessary |
/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, thanks @newly12 for your effort here!
…stic#24622) (cherry picked from commit e2257b9)
…etheus client scraping (#24731)
What does this PR do?
accept text/plain type by default for prometheus client scraping
Why is it important?
prometheus java client 0.10.0 introduced breaking changes that when application/openmetrics-text is seen in accept list, new types(i.e. info) will be exposed and they are not supported by current metrics parser
Checklist
My code follows the style guidelines of this projectI have commented my code, particularly in hard-to-understand areasI have made corresponding changes to the documentationI have made corresponding change to the default configuration filesI have added tests that prove my fix is effective or that my feature worksCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
Related issues
Use cases
Screenshots
Logs